Procs and Locks: A Portable Multiprocessing Platform for Standard ML of New Jersey

in Multilisp) and rely on sophisticated runtime system support ; they don't attempt to be extensible or portable. The Lisp-based system most closely resembling ours is STING [20, 21], a concurrent dialect of Scheme speci-cally intended as a substrate for building higher-level parallel computing environments. STING's basic data types are threads and virtual processors; the system provides ex-ibility in scheduling, storage allocation and thread migration policies while attempting not to compromise eciency. The thread data type is simultaneously lower-level and more complex than an SML/NJ continuation; for example, it includes a thread control block with associated stack, heap segment, saved registers, genealogy information, and other state. Threads are therefore expensive to create, and STING includes several optimizations, such as \thread stealing," to avoid creating new threads when possible. In SML/NJ, threads are represented by simple continuations, which cost almost nothing until they begin executing, so there is no need or opportunity for such optimizations. Similarly, MP has no processor data type; clients can emulate any of STING's scheduling options by explicitly varying queuing disciplines. By using an explicitly stack-based thread model, STING implementations may be able to oer better performance than our continuation-based approach. However, we believe MP presents a simpler view of the multiprocessing environment, which will be easier to port to new hardware and operating system platforms. Matthews [24] describes several implementations of a concurrent extension to Poly/ML using CSP-style communication operators [8]. He describes several implementations, including one for the DEC Fire BLOCKINy multiprocessor. Support for the thread and communication model is hard-wired into the Poly/ML runtime system, and is not designed for easy porting to dierent thread models or hardware platforms. Some existing concurrent systems do stress portabil-ity at the runtime-system level. The Portable Common Runtime system (PCR) [37] oers portable and language-independent facilities for threads, storage management, and other runtime-system features. PCR's implementation of threads is similar to ours: user-level threads are multiplexed on top of kernel threads. However, PCR does not allow the thread package or its scheduling policy to be customized. Although we have stressed simplicity and portability in our MP implementation, better performance is also important. One critical task for the future is to improve the present system's poor locality of reference and consequent memory bus contention. One cause of this problem is SML/NJ's heap-based allocation strategy for procedure frames, which makes callcc and throw cheap relative to ordinary computation but re-uses …